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@ Network agents. 

(57) A network agent system In which the fund:* 
tions of the agent are partitioned between a task 
agent and a user agent for each user of the the 
agent system. The task agent and the user 
agents communicate by means of a protocol 
which is implemented in electronic mail mes- 
sages. The messages of the protocol are Inten- 
sions! rather than extensional, and the 
response of a user agent to a message Is deter- 
mined by the user's hardware environment and 
preferences. The partition of the functions and 
the use of electronic mail as the communi- 
cations medium provide Important advantages 
in the areas of security, privacy, and adaptabi- 
lity. The disclosed network agent Is a scheduler 
for visitors. Features of the scheduler include a 
user Interface which offers more than a yes-no 
choice and the translation of the scheduling 
problem into a general integer programming 
problem. 
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Background of the Invention 
Field of the Invention 

The invention disclosed herein concerns computer 
systems generally and more particularly concerns 
networked computer systems in which agents are 
used to perform remote operations. 

Description of the Prior Art 

The advent of a world in which many computer sys- 
tems are connected by communications networks 
has led to the notion of the network agent A network 
agent is a program which uses resources and infor- 
mation available on the computer systems in the net- 
work to performataskforauserofacomputersystem 
on the network. An example of such a task is sched- 
uling meetings for a visitor. A network visitor agent 
can interact with computer systems attached to the 
network to find out when persons interested in meet- 
ing with the visitor can meet with him, and can then 
use this information to make a schedule which is ac- 
ceptable to everyone. Network agents are described 
in Oren Etzioni, et al, Building softbots for UNIX, Uni- 
versity of Washington Department of Computer Sci- 
ence Technical Report, 1992; Pattie Maes, ed., De- 
signing Autonomous Agents, MIT/Elsevier, 1993; and 
Yoav Shoham, "Agent-oriented Programming, Artifi- 
cial Intelligence, 50:51-92, 1993. 

One system for constructing network agents is 
currently being developed by the General Magic Cor- 
poration. General Magic has created a language 
called Telescript for writing network agent programs. 
Any system connected to the network which has an 
interpreter for the Telescript language can execute 
messages written in Telescript There are two draw-" 
backs to this approach. First, Telescript messages are 
full-fledged programs; i.e., all of the functionality of 
the systenf which receives the telescript message is 
accessible to the telescript message. This in turn 
makes it possible to use Telescript messages to sub- 
vert the systems on which they are run. Put another 
way, with Telescript, one man's network agent might 
be another man's network worm or virus. Second, the 
behavior of a system which is executing a Telescript 
message is completely determined by the message. 
Different systems consequently require different 
messages. Moreover, there is no good way of varying 
what happens when a Telescript message is being 
executed according to the preferences of the entity to 
which the Telescript message is directed. 

In distributed systems generally, security risks 
are minimized by requiring that a user for whom a 
computer system remotely executes a program be a 
user not only of the computer system from which the 
request for remote execution came, but also of the 
computer system upon which the remote execution is 



performed. The difficulty with this approach in the 
network agent area is that the need for the user who 
is employing the agent to be a user of any computer 
system which the agent uses greatly diminishes the 
5 value of agents. 

There is, of course, one way in which a user of 
one computer system can communicate with a user of 
another computer system without being himself a 
user of the other computer system, and that is elec- 
ta tronic mail. Security is achieved here by restricting 
the receipt of electronic mail to an electronic mail 
process. The user can read mail received by the proc- 
ess and if he wants, save the mail in a file accessible 
to the user. In advanced electronic mail systems, the 
15 user can program the electronic mail process to per- 
form actions such as forwarding the user's mail, and 
electronic mail may include portions which, when in- 
terpreted by an electronic mail reader, produce audio, 
video, or images as well as text However, even ad- 
20 vanced electronic mail systems do not provide the 
functions necessary for the development of useful 
agents, nor do they have a capability for adapting to 
the needs of various environments or users. 

What is needed, and what is provided by the ap- 
25 paratus and methods disclosed in the following, is 
network agents which are as capable as those pro- 
duced using the Telescript language but additionally 
are easily adapted to different environments and user 
preferences and are further as safe as electronic mail 
30 messages. 

Summary of the Invention 

The network agents of the invention have two com- 

35 ponents: a task agent and one or more user agents. 
The task agent performs a task using information 
which it requests from the user agents. Communica- 
tion between the task agent and the user agents is by 
electronic mail messages. The task agent obtains in~ 

40 fom^tion from e user agent by sending a message 
which indicates what the user agent is to do, but not 
how the user agent is to do it The user to whom the 
user agent belongs can specify how the user agent is 
to respond to messages from the task agent. The use 

45 of electronic mail as the means of communication be- 
tween the task agent and the user agent and the abil- 
ity of the user to specify how the user agent is to re- 
spond to the message gives the network agents of 
the invention most of the power of prior-art network 

so agents and much more security and flexibility. It is 
thus an object of the invention to provide improved 
network agents. Other objects and advantages of the 
apparatus and methods disclosed herein will be ap- 
parent to those of ordinary skill in the art upon perusal 

55 of the following Drawing and Detailed Description, 
wherein: 
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Brief Description of the Drawing 

FIG. 1 is an overview of the architecture of the 

network agents of the invention; 

FIG. 2 shows a user interface generated by a user s 

agent of the present invention; 

FIG. 3 shows the user interface used to control a 

user agent of the present invention; 

FIG. 4 shows a message sent from a task agent 

to a user agent of the present invention; and 10 

FIG. 5 shows a reply message produced by a user 

agent of the present invention. 

Reference numbers in the Drawing have two 
parts: the two least-significant digits are the number 
of an item in a figure; the remaining digits are the 15 
number of the figure in which the item first appears. 
Thus, an item with the reference number 201 first ap- 
pears in FIG. 2. 

Detailed Description of a Preferred -Embodiment zo 

The following Detailed Description describes a 
scheduling agent which embodies the principles of 
agent construction disclosed herein. The scheduling 
agent schedules a visitor to a site such as a research 25 
laboratory. Agents performing similar functions have 
been described in Maes and Kozierok, "Learning in- 
terface agents", in Proceedings ofAAAI-93, pp. 459- 
464, AAAI Press/The MIT Press, 1993, and L. Dent, 
et ah, "A personal learning apprentice", in Proceed- 30 
ings ofAAAI-92, pp. 96-103, AAAI PressHTie MIT 
Press, 1992. This job is quite routine, but consumes 
a substantial amount of the hosrs.time.The normal 
sequence of tasks consists of announcing the upoom- 
. ing visit by electronic mail; collecting responses from 35 
» people who would like to meet with the visitor, along 
with their preferred meeting times; putting together a 
schedule that satisfies as many constraints as possi- 
ble (taking into account social issues, such as not 
bumping the lab director from the schedule); sending ' 40 
out the schedule to the participants, togetherwith ap- 
propriate information about room and telephone num- 
bers; and, of course, often rescheduling people at the 
last minute because of unforeseen events. 

The preferred embodiment of the scheduling 45 
agent has the design shown in Fig. 1. Agent system 
1 01 includes a task agent (here, visitorbot 1 09), which 
in this case does the actual scheduling, and a user 
agent (here, userbots 103(1 ..3)) for each user of the 
scheduling system. For example, the user agent so 
1 03(1 ) for the user "kautz" is named "kautzbot", agent 
103(3) for "selman" is named "selmanbot", and so on. 
The userbots 103 mediate communication between 
visitorbot 109 and their human owners. Communica- 
tion between visitorbot 109 and the userbots 103 is ss 
by electronic mail messages, indicated by solid lines 
107. The users may also employ electronic mail to 
communicate directly with visitorbot 109. Communi- 



cation between userbots 103 and the users to which 
they belong is by either a graphical interface or elec- 
tronic mail; the combination is indicated by dashed 
lines 105. 

The normal interaction between the visitorbot 
and the users proceeds as follows. Visitorbot 109 
mails an initial talk announcement which is readable 
by the userbots 103 to each userbot 103. Each user- 
bot 103's user has specified to userbot 103 how it is 
to communicate with the user, end each userbot 103 
uses the mode specified by its user in communicating 
the contents of the message received from visitorbot 
109. What happens if the user is logged in on an X- 
terminal and has specified a graphical interface is 
shown in FIG. 2. Userbot 103 creates a pop-up win- 
dow 201 on the user's screen, containing the an- 
nouncement and a button 105 to press to request a 
meeting with the visitor. If the user clicks on "yes", 
userbot 103 passes this information back to visitorbot 
109, which responds with a request to userbot 103 to 
obtain the user's preferred meeting times. Userbot 
103 then creates a graphical menu 207 of meeting 
times. In a preferred embodiment, menu 207 offers 
three choices for each time slot, which permits more 
flexibility in scheduling than the usual yes-no 
choices. The user then simply dicks on buttons to in- 
dicate his or her preferences. Userbot 103 then gen- 
erates a message containing the preferences and 
mails it back to visitorbot 109. If userbot 103 is unable 
to determine the display where the user is working, or 
if the user fails to respond to the pop-up displays, 
userbot 103 forwards the request from visitorbot 109 
via electronic mail to the user as a plain text form. The 
form appears as form 501 in FIG. 5. 

There are several important advantages of this 
design. First, visitorbot 109 does not need to know 
about the user's display, and does not need permis- 
sion to create windows on that display. This means, 
for example, that a visitorbot 1 09 at B.ell Labs can cre- 
ate a graphical window at any site that fe reachable by 
electronic mail where there are userbots 103. It is of 
course sometimes possible to create a remote X-win- 
dow over the internet, but this is prone to failure. 
Among other problems, the user would first have to 
grant permission to fxhost") the machine running the 
visitorbot program; but the user will often not know the 
identity of the machine on which the agent program 
is running. 

The separation of visitorbot 109 from the user- 
bots 103 also simplifies the design of the former, 
since the userbots 103 handle the peculiarities of ad- 
dressing the users' displays. Even more importantly, 
the particular information about the user's location 
and work habits does not have to be made available 
to visitorbot 1 09. This information can be kept private 
to the user and his or her userbot 103. 

Another advantage of this design is that different 
users, who may have access to different computing 
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resources, can run different userbots 109 of varying 
levels of sophistication. Thus, everyone is not re- 
stricted to a "least common denominator* type inter- 
face. 

Perhaps the most important benefit of the design 
is that a task agent (such as visitorbot 1 09) is not tied 
to any specific form of communication with the user. 
The task agent specifies what information is to trans- 
mitted for obtained, but not how the communication 
should take place. In the case of visitorbot 1 09, for ex- 
ample, the message sent from visitorbot 109 to user- 
bot 103 indicates the choices available to users, but 
it is userbot 103 which determines how these choices 
are actually presented to the user. Because that is the 
case, userbot 103 can employ a wide range of media, 
such as graphics, voice, FAX, electronic mail, etc. for 
interacting with its owner. Userbot 103 can also take 
into account its owner's preferences and such factors 
as the owner's whereabouts and current computing 
environment in deckling on the mode of communica- 
tion. For example, a userbot 103 could incorporate a 
telephone interface with a speech synthesizer. This 
would enable a userbot to place a call to its owner (if 
the owner so desires), read the talk announcement, 
and collect the owner's preferences by touch-tone. 
Note that this extension does not require any modifi- 
cations at all to visitorbot 109. 

Communication between Task Agents and User 
Agents: FIG. 4 

In the preferred embodiment, visitorbot 109 commu- 
nicates with userbots 103 by means of a simple set 
of protocols which are implemented as electronic mail 
messages. FIG. 4 shows the electronic mail message 
401 which visitorbot 1 09 sends to a userbot 103 when 
userbot 103 is to solicit its user's time choices. One 
response which userbot 103 can make to this mes- 
sage is window 207. 

* In the preferred embodiment, electronic mail 
messages between agents are identified by a special 
header field, "XBot-message-type" 405. The mes- 
sage type indicates the general way in which the body 
of the message (if any) should be processed by the 
receiver. For example, the message type "xchoices" 
means that the message is a request for the receiver 
to make a series of choices from among one or more 
sets of alternatives described in the body of the mes- 
sage. The inclusion erf the field "XBot-return-note" 
407 in the message indicates that the result of proc- 
essing the message should be mailed back to the 
sender. The communication protocol forthe message 
401 establishes the syntax for the data presented in 
the body 409 of each message type, and the format 
of the data that results from processing the message. 
However, the protocol deliberately does not specify 
the exact method by which the processing is carried 
out For example, a userbot 103 may process an 



xchoioes message 401 by creating a pop-up menu, or 
calling the user on the telephone, or simply by con- 
sulting a database of defaults that the user has estab- 
lished. 

5 When applications are developed that demand 

novel kinds of interactions with userbots 103, the 
communication protocols can be extended by adding 
new message types. This can be done by mailing "up- 
date" messages to the userbots 103 which indicate to 

10 the userbots 1 03 how they are to handle the exten- 
sions. However, the agents which have thus for been 
constructed using the techniques described above 
have required only a very small number of message 
types (namely, ones for requesting choices, request- 

15 ing help, and simply conveying a piece of informa- 
tion). 

In essence, the messages that task bots 109 and 
userbots 103 exchange can be viewed as intensions 
- such as a request to make a choice - rather than ex- 

20 tensions - such as a description of how the userbot is 
to ask the user to make the choice. As pointed out 
above, message 401 does exactly that it indicates 
the set of choices to be made and how the choices are 
to be returned to visitorbot 109, but leaves it up to 

25 userbot 103 how to provide the set of choices to the 
userbot 10 3's user. 

The fact that it is left to usertwt 1 03 to determine 
how the set of choices is displayed to the user also 
makes it possible to take the user's personal prefer- 

30 ences into account For example, some users do not 
wantwindow207 to appear wheneverthe user's user- 
bot 103 receives a message 401 from visitorbot 109. 
Consequently, in the preferred embodiment, the user 
can specify whether he wants windows 207 to auto- 

35 matically pop up. If he does not so specify, userbot 
103 indicates arrival of a message by incrementing a 
counter, and the user chooses when he wants to see 
window 207. Userbot 103 runs continuously, collect- 
ing messages from the task bots 109 as they come 

40 in, and providing the contents of the messages to the 
user h response to requests from the user. 

The displays by means of which the user controls 
the behavior of a userbot 103 in a preferred embodn 
ment are shown in FIG, 3. Main userbot window 303 

45 indicates the number of outstanding messages wait- 
ing to be processed, the userbofs status (working or 
Idle), and three buttons. Clibking on the "process 
messages** button allows the userbot to process mes- 
sages that require user interaction - for example, 

so bringing up an xchoices window on behalf of the vis- 
ftorboL 

The second button, "user preferences", brings up 
a window 305 in which the user can set various op- 
tions in the behavior of his or heruserbot 103. For ex- 
55 ample, checking the "autopilot" box in window 305 
makes userbot 103 pop up windows without waiting 
to be explicitly told to do so. The "voice" checkbox 
causes userbot 103 to announce the receipt of new 

4 
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userbot mail using the speaker in a Sun workstation. 
The "forward to* options are used to indicate that 
userbot 103 should try to communicate with its owner 
at a remote location - for example, by transmitting 
messages via a FAX-modem to the owner's home tel- 
ephone. 

Finally, the third button in the main userbot win- 
dow brings up the window 307 labeled "taskbots". 
This window contains a button for each task agent 
1 09 whose electronic mail address is known to user- 
bot 103. (This information is maintained in file that the 
user can easily customize.) Clicking on a button in 
window 307 initiates communication with the de- 
signed task agent, by sending a message of type 
■help" to that agent The communication protocol spe- 
cifies that the agent respond to a help message by 
sending back a menu of commands that the agent un- 
derstands, together with some basic hel p information, 
typically in the form of an xchoices message. When 
userbot 103 processes this response, it creates a win- 
dow containing the appropriate controls for interact- 
ing with that particular task agent For example, a 
user who is hosting a visitor starts the entire sched- 
uling process by clicking on the visitorbot button. This 
leads to the creation of a window containing buttons 
for basic visitorbot commands, such as scheduling a 
new visitor, getting the status of a visit, ordering a 
schedule to be generated, and so on. Clicking on 
some of these buttons leads to the creation of other 
windows, for example, one in which to type the text of 
the abstract of the visitor's talk. 

It should be pointed out here thatthe calendarbot 
and the f ingerbot are task agents 1 09 which run at re- 
mote sites. Communication between these task 
agents and user agents 103 at other remote sites is 
of course by means of electronic mail across the in- 
ternet 

Privacy and Security 

An important problem in the design of network agents 
is privacy and security. Some proposed agent sys- 
tems would filter through all of the user's electronic 
mail, pulling out and deleting messages thatthe agent 
would like to handle. Users generally object to giving 
a program permission to automatically delete any of 
their incoming mail. An alternative approach would 
give the agent authority to read but not modify the 
user's mail. The problem with this is that the user's 
mail quickly becomes polluted with the many messag- 
es sent between the various agents. 

Our solution to the security problem has been to 
create a pseudo-account for each userbot 103, with 
its own mail alias. Mail sent to this alias is piped into 
userbot 1 03, which is executed underthe correspond- 
ing user's id. This gives userbot 103 the authority, for 
example, to create a window on the user's display. 
Any "bot mail" sent to this alias is notseen by the user, 



unless userbot 1 03 explicitly decides to forward it 

In the preferred embodiment, each user has a 
special ".boF directory, which contains information 
customized to the particular user. These files specify 

5 the particular program that instantiates userbot 1 03, 
a log of the userbot mail, and the user's default dis- 
play id. In general, this directory contains user- 
specific information for userbot 103. The "bot" direc- 
tory also enhances privacy, since the directory b not 

10 public, and can thus contain sensitive information for 
use by userbot 103. Examples of such information in- 
clude the names of people the bot is not supposed to 
respond to, unlisted home telephone numbers, the 
user's personal schedule, and so on. 

is Thus, userbots 103 provide a general mecha- 
nism for the distribution and protection of information. 
For a concrete example, consider the information you 
get by running the UNIX operating system's finger 
command (UNIX is a trademark of Unix System Lab- 

20 oratories). Right now, you have to decide whether 
your home phone number will be available to every- 
one on the in-ternet, or np one at all. Astraightforward 
task of your userbot would be to give out your phone 
number via electronic mail on request from (say) fac- 

25 utty members at your department and people listed in 
your address book, but not to every person who 
knows your login id. 

Unlike agent systems such as the one produced 
by General Magic, user-bot systems are by nature se- 

30 cure, insofar as the routines for processing each mes- 
sage type within the userbot are secure. Although this 
is a non-trivial condition, it would appear to be easier 
to guarantee that the code of the userbot itself (that 
is presumably obtained from a trusted source) is se- 
as cure than to guarantee that every electronic program 
(that could come from anyone) does not contain a vi- 
rus. Extensions and updates to userbots to handle 
new message types would have to be distributed* 
through secure channels, perhaps by using known 

40 cryptographic techniques. # 

Details of the Embodiment 

We now consider a concrete example of the interac- 
ts tion between visitorbot 1 09 and userbot 1 03. Visitor- 
bot 103 wishes to obtain the preferences of a user 
with login name "adman" for meeting with a visitor 
named Oren Etzioni. Visitorbot 109 therefore sends 
electronic mail message 401 to userbot 103(3)for sel- 
so man. This message is routed by the mail system to 
selmanbot 1 03(3). Set manbot window 303 shows that , 
there is mail to be processed (by incrementing the "# 
of botmail items" counter). If the user selman has 
checked the "autopilot" button in the User Preferenc- 
55 es window 305, then the message is processed im- 
mediately; otherwise, it is held until the user presses 
the "process messages" button in window 303. 
In either case, the message is then processed ac- 
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cording to the user's preferences. By default, it is 
graphically displayed, as shown in window 207. The 
user selman then indicates his preferences by clicking 
on the various "bad", "okay", and "good" buttons in 
window 207, and finally clicking on the button "done". 5 
At this point, userbot 103 constructs a message list- 
ing the preferences for the different time slots, and 
mails it back to the visitorbot 

In case the user selman does not respond within 
one hour to the graphical display, or if he has indicat- 10 
ed that he wishes to receive his messages by ordinary 
electronic mail instead of graphically (the preference 
for onJinary electronic mail can be set in the User 
Preferences window by selecting a submenu that ap- 
pears when the button labeled "other..." in window 15 
305 is clicked), userbot 103 converts the visitorbot 
message to the form shown in Fig. 5. The user selman 
reads this message using any ordinary mail-reading 
program, then makes a copy of it, edits the copy to in- 
dicate his preferred meeting times, and mails it back 20 
to visitorbot 109. 

Now visitorbot 109 has obtained the preferred 
meeting times by the userselman. Visitorbot 109 sim- 
ilarly obtains preferences from all of the other users. 
Then it generates a schedule of times for people to 25 
meet with Oren Etzioni. Visitorbot 109 generates the 
schedule by translating the scheduling problem into 
an integer programming problem and solving the in- 
teger programming problem with a general integer 
programming package (CPLEX). An interesting ad- 30 
vantage of this approach is that is easy to incorporate 
soft constraints (such as the difference between an 
"okay" time slot and a "good" time slot fa a user) into 
the scheduling problem. Finally, visitorbot 109 distrib- 
utes the schedule to all of the users. 35 

Mail-based Compute Serving 

The userbot/taskbot architecture of FIG. 1 is an in- 
stance of a new style of client/server computing. 40 

In client/server computing, a server process pro- 
vides services for some number of client processes, 
that may be running on different physical machines. 
One example of this is the well-known Network File 
System used on SUN workstations, where the "nfe 45 
demon" server provides access to files for client proc- 
esses that want to read or write files. Another exam- 
ple is the X-Windows graphics programming environ- 
ment from MIT, where display servers draw graphics 
on display terminals in response to requests from va- so 
rious client programs (such as xterm, a terminal emu- 
lator, or xfig, a drawing program). What is common 
among these kinds of client/server architectures is 
that the client and server programs are tightly cou- 
pled, and require direct, low-level, real-time access 55 
between the client and server machines. 

In the userbot/taskbot architecture, a taskbot 
(such as the visitorbot) provides a service to some 
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number of userbots. Unlike the client/server systems 
just mentioned, however, the userbots and taskbots 
are loosely coupled, and (in our current system) com- 
municate by electronic mail. No direct, low-level ac- 
cess is required between the userbot and taskbot ma- 
chines. This provides a number of advantages: 

• The client programs do not require detailed 
knowledge about the machine the server is 
running on, and vioe-versa. For example, the 
client program would not need b know informa- 
tion such as the ether net number, nor the inter- 
net numbers, nor even the actual machine 
name for server program. For example, a user- 
bot can establish contact with the visitorbot 
running in our laboratory simply by sending 
electronic mail to the address "vis'itorbot@re- 
search.att.oom". The mail system running in 
the "reseanch.att.oom" domain then directs the 
mail to the proper machine. It is trivial for the 
person maintaining the visitorbot system to 
change the machine^ the visitorbot runs on, by 
simply installing the software elsewhere and 
appropriately editing the local "mail alias" file, 
which is used to route the mail to a particular 
machine. Note that the client programs would 
not need to be informed of the change; the ac- 
tual location of the server program is effective- 
ly invisible to them. 

• Electronic mail access between client and ser- 
ver programs is often practical in situations 
where more direct, low-level access (such as 
through a remote procedure call) is impossible. 
Low level access is often deliberated blocked * 
between computer networks for purposes of 
system security. Furthermore, even if low-level 
access can be establish, it can be easily dis- 

- rupted if the computer at either end of the link, 
or any of the machines in between that main- 
tain the link, crashes or become temporarily in- 
operative: In contrast, electronic mail systems 
are typically designed to function even in the 
face of machine failures; for example, when a 
machine fails, the electronic mail it is in the 
middle of processing is typically stored in a 
special "spool" file, and then, when the ma- 
chine becomes operational again, the mail is 
processed again withoutany loss of messages. 

• Security of communication between the client 
and server programs is inherited from the se- 
curity of the mail system. Thus, if a secure ma h 
ler is installed (i.e. one based on cryptographic 
encodings of messages), then communication 
between the clients and servers is made 
equally secure, without modification of those 
programs. 

Recently systems that provide electronic-mail 
based information services have become popular. An 
example of such a mail-based service is "Netlib". In 
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this approach, the human user mails a message con- 
taining a command (from a restricted set of com- 
mands) to the service provider, which then responds 
by executing the command and mailing some result 
back to the user. For example, a person can mail a s 
message of the form 
To: netUb@research.att.com 
send README from ampl/src 
and the Netlib program will mail back the contents of 
the file named "README" that is stored in the subdir- 1 o 
ectory "ampl/src" in Netlib system. 

Electronic mail information systems are thus 
closely related to for mail-based compute serving 
with the userbot/taskbot architecture. The important 
difference is that our approach includes both a ser- is 
vice-providing taskbot and one or more userbots that 
are specially-designed to interact with each other. 
Systems such as Netlib only provide one-half of the 
equation; thus, interaction with systems such as Net- 
lib is difficult for human users and is prone to failure zo 
due to typing errors, formatting errors, and so forth. 
Thus userbots greatly enhance the ease of use of 
mail-based servers. 

Furthermore, in the future userbots could greatly 
expand the kind of services that the servers can pro- 25 
vide. For example, completing some task may involve 
having a userbot and a taskbot exchange a series of 
electronic mail messages without direct human inter- 
vention, such as communicating certain user prefer- 
ences and authority levels. 30 

Conclusion 

The foregoing Detailed Description has disclosed to 
those skilled in the art how to construct a network 35 
agent system which includes a task agent for a task 
such as scheduling and a user agent for each user for 
which the task must be performed. The task agent 
and the user agents communicate by means of a pro- 
tocol implemented in electronic mail messages. The 40 
partition of the functions of the network agent system 
into functions performed by the task agent and func- 
tions performed by the user agent provides important 
advantages in the areas of security, privacy, and 
adaptability both to different types of systems and to 45 
different user preferences. 

The Detailed Description has also disclosed the 
best mode presently known to the inventors of making 
a visitor scheduling system which incorporates the 
principles of the invention. Of course, many other so 
agent systems could be constructed according to the 
principles disclosed herein. Moreover, different proto- 
cols could be used in the electronic mail messages 
used to communicate between components of the 
agent system disclosed herein, and communications 55 
means other than electronic mail could be employed 
to carry the messages. Additionally, the windows dis- 
closed herein are specific to the preferred embodi- 



ment. Agent systems performing other tasks will of 
course have other displays, and even the visitorbot 
system of the preferred embodiment can employ dif- 
ferent user interfaces from those disclosed herein. 



Claims 

1. Apparatus for implementing an agent which per- 
forms a task for one or more entities in a computer 
system, 

the apparatus comprising: 

a task agentfor performing aspects of the 
task which involve more than one of the entities; 

an entity agent associated with each of the 
entities; and « 

means for transferring messages gov- 
erned by a common protocol between the task 
agent and the entity agents, each entity agent re- 
sponding to the messages in a fashion which va- 
ries according at least to the environment of the 
entity agent's entity. 

2. Apparatus including a client and a server, the ap- 
paratus being used in an environment having an 
electronic mail system for transferring electronic 
mail messages and 

the apparatus having the improvement compris- 
ing: 

means in the client for generating elec- 
tronic mail messages for the server according to 
a protocol and responding to electronic mail mes- 
sages from the server according to the protocol 
and 

means in the server for generating elec- 
tronic mail messages for the client according to 
the protocol and responding to electronic mail 
messages from the client according to the proto- 
col. 
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xxx Talk Announcement xxx 

Softbots as Testbeds for AI 
Oren Etzioni 
Univ. of Washington 

I will describe our project to develop 
UNIX softbots (software robots) — complete 
intelligent agents that interact with UNIX. 

11: 00 aa Thurs Jan 20. room 2B-402 
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Message from Visitorbot 
(11: 20am Tues Jan 18) 
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FIG. 4 
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From: v isitorbot&gr ace land . ih . att . com 
Oate:Tues Jan IB 11:20:59 1994 
Reply-To: v is itorbo tegrace land . ih . att .com 
To: selmanbot@research.att.con 
Xbot-name: visitorbot 
Subjects: prefs 
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XBot-message-type: xchoices 



-405 



XBot-return-note: <visitorbot: prefs regarding Oren Etzioni on 2/18 



beginjieader 

indicate tine 

to neet with Oren Etzioni 

on Thursday. January 20. 

endjeader 
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FIG. 5 

501 

From: visitorbotigraceland. in .att.cooT 
Date: Tues Jan 18 11: 20: 59 1994 
Reply-To: v is itorbotigraceland . ih . att . con 
To: seltan@research.att.com 
Subject: prefs 

Please edit this form to indicate tine 

to neet with Oren Etzioni on Thursday. January 20 

and returned to visitorbot§graceland.ih.att.con. 

For each line below, delete unwanted options. 

xx* 10: 30 bad okay good 
xxx li: 00 Talk - 4C-507 
xxx 11: 30 bad okay good 
xx* 12:00 Lunch no yes 
xxx 1:30 bad okay good 
xxx 2: 00 bad okay good 
xxx 2: 30 bad okay good 
xxx 3:00 bad okay good 
xxx 3:30 bad okay good 

Please do not delete the following line: 

XBot-return-note: <visitorbot: prefs regarding Oren Etzioni on 2/18> 



11 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



BEST AVAILABLE IMAGES 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 



111 BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHD3IT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



III FADED TEXT OR DRAWING 



